Search

看了底下很多朋友的回覆,我也來補充一下我的想法。

我覺得可以以團隊當單位跟例子...

  • Share this:

看了底下很多朋友的回覆,我也來補充一下我的想法。

我覺得可以以團隊當單位跟例子來看,例如:原本可能是2個前端、2個後端,各自專精各自的部分。

如果可以的話,變成2個全端(前後端工作都能做,不一定要都很專精),另1個專精前端,另一個專精後端。

最後就是「這是一個全端,也就是 cross-function team」,裡面每個人有自己專精的領域,並跟團隊其他成員互補,但同時只要是產品需要做的事,大家都願意做、願意學、互相 cover, value-first。

每個人仍然有喜歡、不喜歡,專精/不擅長的領域。

但是以產品、價值為優先序。

產品團隊這樣在一起互相學習與支援,榮辱與共,慢慢組織才有機會變成學習型組織,一起打仗的團隊也才會有革命情感,也可以避免產品交付出現問題時的爭功諉過或責任歸屬。

其實這並沒有大家想像中的遙遠或困難。我們親身經歷過不少這樣的團隊,也在企業客戶那邊帶過不少這樣的團隊,甚至團隊內還有 designer 的人員,除了 design/切版,他們還可以 cover 一點js 跟測試。當然,也會跟 PO 合作,分擔 PO 的一些工作。

這也是為什麼,鈦坦的工程師是用 Product developer, PD 來稱呼,而不是 F2E 或後端工程師, developer/tester來稱呼。

順帶一提,這跟 pair programming 引入的思路有一點點類似。

原本是2個人各自領一個 task, 轉換成 2個人一起領2個 task. 在 ownership 上、設計盲點、團隊學習、成員備援,都會發揮很好的效果。

慢慢得更像一個 Co-work的 team,而不是只有分工、沒有合作的 group。


Tags:

About author
我是 Joey Chen,闖蕩江湖的稱號是 91,熱血點火師,專門燃起大家心裡面的熱情與初衷。 目前為 Odd-e Taiwan 的負責人,同時也是 JetBrains 在台灣的培訓夥伴,至今也仍是熱愛學習與享受各種程式語言之美的 programmer。 身為敏捷教練,擅長 Agile、Scrum、LeSS 等敏捷文化與協作框架的落實與導入,如何讓大家 being agile 而不是 doing agile。同時喜歡結合各家所長,例如 Lean, Kanban 等,重點是持續改善、解決問題、端出成果,而不執著於某種特定方法論或框架。 身為技術教練,我也是極限編程(extreme programming)的狂熱者,我擅長用這些技術與工程實踐來提昇產品的品質、團隊的生產力、降低營運風險,因應市場與公司的商業目標,讓團隊能具有高適應與反應能力的基礎建設。例如 實例化需求、ATDD、BDD、TDD、重構、自動化單元測試/整合測試/驗收測試、CI/CD、code review、pair programming、mob-programming 等等。 同時,我也是推崇 極速開發 的 developer,追求從想法到產品程式碼的完成,中間的時間差能趨近於零,也就是劍隨心轉,想到哪,程式碼就長到哪的境界。從想法到實現中間的等待,其實在實務上佔了很大的 context switch 成本,如果能讓這段時間縮到最短,就能比其他人多嘗試更多種解決方案,進而挑選出最剛好的方案。 同時也是技術社群的活躍份子,從 2010 年開始連任九屆的微軟 MVP,兼任 MSDN 論壇板主,也曾經獲得年度 MSDN 文件庫刊登數量世界第一的榮耀。對微軟技術有愛,對 C# 有愛,對自動測試有愛,對重構與設計模式有愛。近年來對 Java, PHP, Python 也充滿濃厚的興趣,曾帶領客戶團隊中不會寫程式的 QA ,一起用 Python 完成超過百個 mobile UI 自動化測試。 擁有超過十年擔任開發團隊 tech leader, trainer, coach 與 mentor 的經驗,進行的企業內部與公開技術培訓課程已超過 100 場,培訓過的開發人員超過 1000 位,擔任研討會與社群活動的講師次數超過 30 次。 同時也是技術書籍的作者與譯者,與朋友合著的書籍包含《ASP.NET MVC 5:網站開發美學》、《ASP.NET MVC 4 網站開發美學》,翻譯的書籍有《單元測試的藝術-第二版》、《敏捷開發實踐》、《進入IT產業必讀的200個 .NET面試決勝題》。 如果想跟我即時互動,歡迎直接私訊或 email 至 [email protected]
請參考:https://tdd.best/about/
View all posts